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Recent projects that attempt to bring app-like permissions to the web are requiring more 
powerful features of website permissions. The overall system is fairly complex, making it hard 
for users to understand. This means it is difficult to build a good UI explaining users’ permission 
settings. This has forced an audit of the existing system that delivers website permissions, 
which is backed off Chrome’s content settings system. The content settings system, although 
powerful, has not been designed to properly enforce the same-origin security policies required 
when reading and writing website permissions. For this reason, studies of website permissions 
have unveiled inconsistent and sometimes insecure behavior across Chrome. 


This document aims to both report the current behavior of website permissions in Chrome, as 
well aS propose a new model that better captures the goals of website permissions. The new 
model is a simple specialization of the existing one, with improved and canonicalized behavior 
that ensures website permissions are saved consistently and align with Chrome’s security goals. 


1 Introduction 


First, let us distinguish between the 3 kinds of settings: 


1. Website settings are the most general kind of setting - it can store any serializable data 
for a given primary and secondary URL pattern and a website settings type (see 
content_settings types.h) 

2. Content settings are a specialized form of website setting which stores and retrieves an 
enum value, which can be one of 5 options (Allow, Block, Ask, Session or Detect - see 
content_settings.h) 

3. In this document we propose a further specialization, website permissions, which are a 
specialized form of content settings that store and retrieve only an Ask/Allow/Block 
value, and can only be saved using enforced origin rules. Website permissions currently 
exist, but are not distinguishable from content settings, and hence many website 
permissions are saved poorly or incorrectly since they are not a well-defined layer on top 
of content settings. 

a. Note: In future, this will be insufficient for all permissions (e.g. Bluetooth will need 
to save device IDs and metadata, geolocation needs to store granularity, etc). 
Once all website permissions are saved uniformly, one option might be to 
completely remove the content settings layer, storing website permissions directly 
using website settings. Then, a WebsitePermission class (with protected 
read/write functions) could be made, which can be overridden by each 
permission to read and write its own custom serializable data, or use an 
abstraction like content settings to just store Ask/Allow/Block. 


Chrome stores the values of all the above settings using a common format, and the storage 
mechanism for storing these settings is excellent. However, given the freedom content settings 
provide, many settings are being stored inconsistently and forming unified Uls (e.g. a list of all 
settings for a given site) is difficult. More importantly, the user is given an inconsistent browsing 
experience, since granting some permissions gives access to more URLs than granting others. 
This problem of inconsistent access across different website permissions is the main cause of 
concern. 


1.1 Website settings 


A website setting is a way of saving data related to a user’s browsing activity on a website, or 
set of websites. Applied to a set of URLs, a website setting saves data that applies to a user’s 
profile to disk. These settings are not synced across devices but are loaded from disk each time 
the user opens Chrome. 


Any serializable data can be stored with a website setting. For example, 
CONTENT SETTINGS TYPE_AUTO SELECT CERTIFICATE Stores a filter set by enterprise policy, which 
contains a set of strings to match when selecting client certificates. 


Currently, there are 23 website settings keys that data can be stored against: 


Enum Name WS CS WP Stores whether or not this site can... 


CONTENT SETTINGS TYPE COOKIES read/save cookies 
CONTENT SETTINGS TYPE IMAGES 
CONTENT SETTINGS TYPE JAVASCRIPT 
CONTENT SETTINGS TYPE PLUGINS 
CONTENT SETTINGS TYPE POPUPS 


CONTENT SETTINGS TYPE _GEOLOCATION 


display images 
run Javascript 
run external plugins 


show popups 


<x |X |X TK TX |X 
x KX) KX KK XK 
x {XX RK XK 


access the user’s location 


send custom notifications (to the user’s phone, or 


CONTENT SETTINGS TYPE NOTIFICATIONS X X X ERE 
z -= -= notification centre) 


automatically select a client SSL certificate (if not, 
CONTENT_SETTINGS_TYPE_AUTO SELECT_CERTIFICATE X X Chrome will show an SSL certificate selector to the 
user when a certificate is requested) 


CONTENT_SETTINGS_TYPE_FULLSCREEN 
CONTENT_SETTINGS_TYPE_MOUSELOCK 
CONTENT_SETTINGS_TYPE_MIXEDSCRIPT 
CONTENT_SETTINGS_TYPE_MEDIASTREAM 
CONTENT_SETTINGS_TYPE_MEDIASTREAM_MIC 
CONTENT_SETTINGS_TYPE_MEDIASTREAM_CAMERA 
CONTENT_SETTINGS_TYPE_PROTOCOL_HANDLERS 
CONTENT_SETTINGS_TYPE_PPAPI_BROKER 
CONTENT_SETTINGS_TYPE_AUTOMATIC_DOWNLOADS 
CONTENT_SETTINGS_TYPE_MIDI_SYSEX 
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING 


x display in fullscreen 

x hide the mouse cursor 

display insecure content 

access the camera, microphone, or both 

(the MEDIASTREAM setting is being deprecated, and 
MIC and CAMERA will be website settings instead) 
register custom protocol handlers 

register a custom Pepper broker 

x start multiple downloads 


x have full control over MIDI devices 


X | K LK | KOT KO CK OU KOT CK Ud KOU] CK |X 
x | K TK | KO TK | KOT XK | mK OT XK | CK |X 


x send push messages 


<not a permission> caches previous SSL certificate 


CONTENT SETTINGS TYPE SSL CERT DECISIONS xX s 
= = = = decisions 


CONTENT_SETTINGS_TYPE_METRO_SWITCH_TO_DESKTOP| x unknown. Windows only. 


CONTENT SETTINGS TYPE PROTECTED MEDIA IDENTIFIE . unknown. Android/ChromeOS only. Seems related to 
R platform verification flow. 


display an infobar on Android, prompting the user to 


CONTENT SETTINGS TYPE APP BANNER X X oe 
-= = ——— install the website’s app 


WS: Website Setting, CS: Content Setting, WP: Website Permission. 


Source:_src/components/content_settings/core/common/content_settings tvoes.h and code references. Some 
settings are deprecated or no longer used, so their current use may be unclear. More detail on some of these 


settings may be found in the Chrome APIs and their limitations doc. 


Many of these simply save a permission setting (e.g. ‘Ask every time’, ‘Allow’ or ‘Block’), but 
some save other settings (e.g. ‘Session only’ or ‘Detect important content’), or don’t save a 
permission setting at all (e.g. SSL certificate decisions saves a serializable dictionary). Without a 
different interface for website permissions, content settings and website settings, there’s no way 
of knowing what data was intended to be stored. This means that each callsite needs to know 
how to interpret the stored data based on the enum key used to store it. 


For an example of why this can be problematic, see the large switch-statement in 
WebsiteSettings::OnSitePermissionChanged(). Here, each enum needs its own treatment since 
its origin is stored slightly differently, even though all these permissions can really be abstracted 
and stored in the same way. For content types that store actual data (e.g. 
CONTENT_SETTINGS_TYPE_AUTO SELECT CERTIFICATE), this problem is even worse, since each 
callsite needs to know how to serialize and interpret the data (although for now, since there is 
only one callsite, the problem is not as apparent). 


1.2 Content settings 


Content settings are a specialization of website settings which save a permission setting (e.g. 
‘Ask every time’, ‘Allow’ or ‘Block’) that represents whether or not that website can use a 
particular feature or execute a certain behavior. For example, a user may wish to allow a plugin 
for all sites from a given domain (e.g. youtube.com). This can be stored by setting 
CONTENT SETTINGS TYPE PLUGINS tO CONTENT SETTING ALLOW for all URLs with the domain 
youtube.com, with any scheme, port or subdomain. 


However, this is not limited to user-specified permissions - for example, the settings 
CONTENT SETTING SESSION ONLY and CONTENT SETTING DETECT_IMPORTANT CONTENT are valid values for 
only one content setting each (CONTENT_SETTINGS TYPE_COOKIES and 
CONTENT_SETTINGS TYPE_PLUGINS, respectively). It is an error to set any other website 
permissions to these values, but this is not enforced at a code level since these are valid values 
for the content setting. This is a side effect of not having a consistent interface, and results in 
code that constantly checks whether the returned value is valid - see 


HostContentSettingsMap::|IsSettingAllowedForType(), which is used in some places (but not 


others) to check if the setting requested is valid for the given type. 


1.3 Website permissions 


We define a website permission as a content setting that a user sees as grantable or 
blockable for a website. Website permissions currently exist, but at a code level are virtually 
indistinguishable from non-permission content settings. 


A user is able to grant or deny a website permission for a site (either by prompt or manual 
allow/block), can see the setting of the permission at any time, and is able to later revoke any 
permission decisions. For example, when a website requests to see the user’s location, the user 
can select ‘Allow’ or ‘Deny’. On Android, the infobar is displayed at the bottom of the screen, 
and on Desktop, it’s displayed at the top, below the omnibox: 











Q http://adrifelt.github.io wants to use >< 
your device's location. C ff Q https://adrifelt.github.io/all-permissions.htm! 
ae ine B® Allow https://adrifelt.github.io to show desktop notifications? | Allow | | Block | 





The user can later change this permission setting from one of the Origin Info bubbles: 


@ https://adrifelt.github.io/all-permissions.htr 
| | | 
l atest | 


Identity verified 


(aa) 





http://adrifelt.github.io/all-permissions.html = Settings 





issions C ectio ; a tee , 
Jas eee Your connection to this site is not private. 


Site 

Cookies and site data 

E COPY URL . ; : 
@ adrifelt.github.io (0 allowed / 0 blocked) ere 

e r 
G Others (0 allowed / 0 blocked) | (e) Location Permissions 
Show cookies and site data Allow x i 
a ae Ree a aoe 9 Location access 
a nE Allow 

ermissions 


Lal Images: Allowed by default ¥ 
y=?) JavaScript: Allowed by default ¥ 
b.b Plugins: Allowed by default v 
CX Popups: Blocked by default ¥ 

»} Location: Allowed by you ¥ 
|__| Notifications: Allowed by you ¥ 
Fullscreen: Ask by default ¥ 
Ò Mouse Lock: Ask by default ¥ 
[K] Media: Ask by default v 


# Automatic Downloads: Ask by default ¥ 








On Desktop, the Origin Info On Android, it can be Android also has an 
bubble is opened by clicking opened by clicking the lock additional Origin Info-like 
the lock icon in the omnibox icon or long-pressing on the screen, the Single Site 
URL bar settings page, which is 
accessible by navigating to 
Site Settings and finding the 

corresponding site 


Not all permissions require prompting, though; for example, websites do not prompt the user 
before they can execute Javascript. However, the user can change the global setting for 
Javascript (blocking it for all sites) or add an exception to only block it for a certain site. 


Setting the global settings and adding manual exceptions for sites can be done from one of the 
global site settings pages (note that, on Desktop, the site settings page is not site-centric but 
pattern-centric, giving a slightly different experience to that on Android): 





r x . . 
Content settings €& Site settings 
Cookies = All sites 
@) Allow local data to be set (recommended) 
Cookies 
Keep local data only until you quit your browser & Allow sites to save and read cookie 
data 
Block sites from setting any data 
Block third-party cookies and site data 9 Location 
Ask first 
Manage exceptions... All cookies and site data... 
= Camera or microphone 
Images Ask first 
@) Show all images (recommended) 
. =J JavaScript 
Do not show any images Allow sites to run JavaScript 
Manage exceptions... 
Z Pop-ups 
Blocked 
JavaScript 
@) Allow all sites to run JavaScript (recommended) be Protected content 
. Ask first 
Do not allow any site to run JavaScript 
Manage exceptions... 
Handlers 
| Done | 
Allow all sites to run JavaScript 
Recommended 
: i x 
Plug-in exceptions 
Block - 5 
Hostname pattern Behavior Allow - 75 


chrome-extension://beknehfpfkghjoafdifaflglpjkojoco/ 


@ https://exposure.so 
https://[*.]mail.google.com:443 


Embedded on https://buzzfeed.com 





https://medium.com 








Allow 
Ask 
Block https://teehanlax.com 
https://cnn.com 
https://drive.google.com 
Learn more | Done | 





https://youtube.com 





On Desktop, the Content Settings page can be On Android, the Site Settings page can be 
opened by clicking ‘Content settings’ in the opened by clicking ‘Site settings’ on Chrome’s 
advanced section of chrome: //settings preferences page 


At a code level, there is currently no distinction between website permissions and content 
settings. Dialogs that display permissions iterate over a list of permissions to display, and error 
out if they encounter an enum value they do not expect (e.g. website _settings.cc, which 
displays the Origin Info bubble on Desktop). If website permissions were distinguishable from 
content settings, iterating over all valid permissions would be simple and the code for these 
sites would be massively simplified. Furthermore, if the saving logic were all abstracted into one 
place (since it should be the same for all web permission types), not only would the code not be 
duplicated across these dialogs but the behavior would be consistent. 


For example, when a user selects ‘Allow’ or ‘Block’ in an infobar prompt, the behavior applied to 
this permission must be the same for all permissions requested this way - if granting 
‘Notifications’ grants to all subdomains of the given URL, granting ‘Location’ should grant to the 
same set of URLs. In general, they are requested in the same manner, the user would rightly 
expect them to behave the same way. This is currently not the case. 


2 Patterns 


Patterns are used to store the site(s) a particular website setting applies to. A pattern can be 
represented as a special URL string with potential wildcard slots. 


For example, the pattern https://[.*]google.com:443 matches https://google.com or 
any of its subdomains on port 443, whereas the pattern google.com matches only the root 
domain google.com, but on any scheme and port. 


Each website setting is saved with 2 patterns: a primary pattern (representing the pattern of 
the website to save the setting to) and a secondary pattern (representing the pattern of the 
iframe to save the setting to). 


Unfortunately, the meaning of these patterns is determined by the caller, as both URLs are 
passed in when the setting is requested. For example, many patterns save the URL of the ‘root’ 
website (no iframe) as both the primary and secondary pattern, = e.g. 
(https://google.com:8@, https://google.com:80) . However, if a caller tries to read this 
setting by passing in the URL of an iframe as the second parameter, the permission may be 
misinterpreted as allowing iframes from google.com inside the website google.com (and not 
the root website as intended). Other permissions, such as the Popups permission, save this 
setting as (http://google.com:80, *) , which can be similarly misinterpreted. 


2.1 Storing website permissions 


Patterns were originally created as a way to allow people to whitelist all subdomains (e.g. allow 
all plugins on [*. ]youtube.com). They’re not based on origins, but have evolved to serve as 
origin specifiers out of convenience. The way various website settings are stored is inconsistent 
between settings, and this is fine so long as the settings are not expected to be comparable to 
each other. However, with the need to create a ‘single site’ view of a website’s permissions, it 
has become increasingly important that website permissions are stored consistently. This 
means that there is a layer missing that canonicalizes what URLs website permissions 
specifically are stored against. 


For example, granting the ‘location’ website permission on a site should grant to the same 
scope as if the ‘camera’ permission was granted on the same site. This is currently not the case 
- granting the ‘location’ permission, for example, grants only to the exact site that it was 
requested on (e.g. http://google.com:80 ), whereas granting the ‘mouselock’ or ‘push 
messaging permission grants to all sites with the same host, but any port and scheme (e.g. 
[*.]google.com ). This inconsistency presents both a confusing experience for the user and 
an inconsistent experience from a security perspective. 


Some of the patterns used to store website permissions can be seen in the following table, 
which was created from the HTTP patterns saved with the Website Settings dialog (in 


website _settings.cc): 


Website permission Primary pattern Secondary pattern 

CONTENT_SETTINGS_TYPE_IMAGES|[*.]google.com á 
CONTENT_SETTINGS_TYPE_JAVASCRIPT [*.]google.com i 
CONTENT_SETTINGS_TYPE_PLUGINS [*.]google.com * 
CONTENT_SETTINGS_TYPE_POPUPS | [*.]google.com : 

CONTENT_SETTINGS_TYPE_GEOLOCATION http://google.com:80 http://google.com:80 
CONTENT_SETTINGS_TYPE_NOTIFICATIONS http://google.com:80 i 
CONTENT_SETTINGS_TYPE_FULLSCREEN [*.]google.com i 
CONTENT_SETTINGS_TYPE_MOUSELOCK |[*.]google.com * 
CONTENT_SETTINGS_TYPE_MEDIASTREAM http://google.com:80 £ 
CONTENT_SETTINGS_TYPE_AUTOMATIC_DOWNLOADS |[*.]google.com 

CONTENT_SETTINGS TYPE _MIDI_SYSEX http://google.com:80 http://google.com:80 
CONTENT_SETTINGS TYPE_PUSH_ MESSAGING | [*.]google.com ý 


Ideally, all these patterns would be the same, and they would all reflect the origin on which the 
permission was requested. More details on some of these settings may be found in the 


Permission Debugging doc. 


There are two main problems that are caused from saving web permissions with inconsistent 
patterns: 


1. It is unclear what the purpose of the primary and secondary patterns are, or why some 
permissions have a different pattern set to others 
a. There is also no guarantee that other callsites reading or writing the same 
permissions will Know what the purposes are, and there could indeed be bugs 
caused from this inconsistency 
2. No patterns reflect the proper isolation of an origin 
a. An origin, as defined by RFC 6454, is defined by the host, scheme and port of a 
URL (for HTTP and HTTPS urls, with slightly differing rules for other URL types) 
b. This violates Chrome’s same-origin security policy - granting a permission on one 
origin should not grant it on any other origin 


To fix this, all website permissions should be stored with the same origin definition, and the 
same primary/secondary pattern rules. Furthermore, this logic can be safely abstracted so all 
callsites are forced to save all website permissions consistently and securely. 


2.2 Iframes 


Its also worth mentioning that it is unclear whether a permissions behavior has been proposed 
for iframes or whether one has resulted from the implementation of permissions for non-iframe 
websites. Currently, when an iframe requests a permission, it is prompted for in the same way 
as when the root website requests the permission (in an infobar or similar), but does not appear 
in any of the Origin Info bubbles as it has not been set for the root URL of the page. This results 
in a confusing experience for users, who have granted or blocked a permission and have no 
clear way of revoking it. 


Furthermore, once a permission is granted for that iframe, it will still be requested on every site 
that embeds the same iframe, as well as on the iframe’s origin itself if visited. For example, if the 
user grants the ‘location’ permission to maps . google.com embedded in an iframe, they will be 
requested for that same permission on any other website that embeds maps. google.com, as 
well as on maps.google.com itself. This seems overly cautious (if a user trusts 
maps.google.com, does it make sense to auto-grant the same permission wherever this origin 
appears?) but a discussion on how to safely auto-grant permissions belongs in another 
discussion. For now, we should continue to support this behavior as it is conservative with 
regards to permission granting. 


A new proposal for iframe behavior, Securing third-party permission usage, is currently 
underway that adds a new attribute to iframes to declare the permissions it requests. See the 
‘Future Work’ section for more details. 


3 Website Permission Ul surfaces 


There are currently four main UI surfaces where website permissions can be modified. This 
section documents each of these locations and how they are intended to work. 


3.1 Infobars and prompts 
There are currently two types of website permissions, categorized by how they are prompted: 


e Explicit website permissions, which are prompted for when requested/used 
o Includes all permissions except Images and Javascript 
o Are usually requested with an infobar (or a permission bubble) 
m Infobars on Android appear at the bottom of the screen: 


Q = http://adrifelt.github.io wants to use Xx 
your device's location. 


DENY ALLOW 





m Infobars on Desktop appear at the top of the screen: 





C f &@ hittps://adrifelt.github.io/all-permissions.html 


® Allow https://adrifelt.github.io to show desktop notifications? | Allow | | Block | 


o Not necessarily set to ‘Ask’ by default 
= ‘Popups’ is set to ‘Blocked’ by default, and is shown in the action bar 


when it blocks a popup: 
I Pop-up blocked 


The following pop-ups were blocked on this page: 





E 


http://www. popuptest.com,/popup3s.html 


htt www popuptest.com/popup html 


E 





E 





http://www. popuptest.com,/ popups.html 
http://www. popuptest.com,/ popupb.html 


E 





L i 


Always allow pop-ups from www.popuptest.com 


e) Continue blocking pop-ups 


Manage pop-up blocking... Done 


m ‘Fullscreen’ cannot be blocked for a site, but can be escaped by selecting 
‘Exit full screen’ in the prompt that appears when the site goes fullscreen: 


or 4STiAn 


adrifelt.github.io is now Tull screen. 


Allow 


ALLAI 


Exit full screen i 


lia a AT = 7 9 =S Mm 
e Implicit website permissions, which are allowed by default and never prompted for, 
although they can be globally enabled/disabled for all sites (and exceptions can be set 


for individual sites): 


o Includes only Images and Javascript for now 


3.2 Action bar (desktop only) 


The action bar is an icon that appears on the right-hand side of the omnibox when certain 
permissions are active. Current permissions that use it include Camera, Microphone and the 
Location permission, as well as the Active Mixed Content shield (although there are plans to 


remove it). 


or” 





This page has been blocked from accessing your camera and microphone. 


Always allow adrifelt.github.io to access your camera and microphone 


è) Continue blocking camera and microphone access 


Microphone: None available v 


Camera v 
a 
| Manage media settings... Done 








3.3 Origin Info Bubble 


This page contains elements from the following sites that are tracking your location: 


| adrifelt.github.io 


Clear these settings for future visits 


Manage location settings... e location settings.. 


Done 


The origin info bubble displays a summary of the connection status of the page, as well as any 
permissions the page has. On Desktop, all permissions are displayed, but on Android only 
permissions that are not set to the default value (permissions that have been modified by the 


user at some point) are shown. 


Desktop 


Android 


Android (Single Site View) 


—~— 


@ https://adrifelt.github.io/all-permissions.ht: 





adrifelt.github.io i 
DU http://adrifelt.github.io/all-permissions.htm! < Settings 
Your connection to this site is not private. 
Permissions Connection Site 
Cookies and site data COPY URL adrifelt.github.io 
@ adrifelt.github.io (0 allowed / 0 blocked) i 
Q Location Permissions 
@ Others (0 allowed / 0 blocked) Allow v 


Location access 
Allow 


Show cookies and site data 9 
Permissions 

lal Images: Allowed by default ¥ 
=) JavaScript: Allowed by default v 
b.b Plugins: Allowed by default v 
[x Popups: Blocked by default v 

®) Location: Allowed by you ¥ 
|| Notifications: Allowed by you ¥ 
Fullscreen: Ask by default ¥ 

[Ss Mouse Lock: Ask by default » 


[k] Media: Ask by default v 


Currently, iframe permissions are not shown in the origin info bubble. In Android’s Single Site 
view, a site entry will appear with the subtitle ‘Embedded in <origin>’ to show that it’s referring to 
the embedded iframe in another site. 








One suggestion to display iframe permissions in Origin Info was to add an extra section at the 
bottom of the bubble with text similar to ‘3 permissions granted to https://foo.com’, which links to 
the Single Site settings page for that iframe. This has yet to be discussed with UI. 


3.4 Site Settings (Android only) 
The site settings page in Android has 3 main sections: 


1. Global site settings: Lists all permissions, their default value if they are enabled, and 
appropriate text if they are disabled 

2. Single setting: A list of all sites that have used (or have tried to use) a given permission, 
as well as the default permission value and any sites with a custom setting 

3. ‘All Sites’ list: A list of all sites that have custom permissions 


Global Site Settings Single Setting ‘All Sites’ List 





as ir a 


Æ Allsites off 
Block all sites 





© 


https://exposure.so 


© Cookies Ea = https://medium.com 
Allow local data to be set Exceptions - 3 PX 
i , l https://teehanlax.com 
t, Automatic downloads O Ea = https://medium.com 5 min ago 
Off - blocked for all sites 
https://enn.com 
https://teehanlax.com 1 week ago 
Fullscreen © 
i @  https://drive.google.com 
iiaii https://cnn.com 08/13/14 i ie 
Im @  https://youtube.com 
m agea + ADDSITE pe 
Allow 
https://huffingtonpost.com 
Q Location -_@ 


Allow sites to ask 


Ed 
mu 


https://buzzfeed.com 


Notifications 
Allow sites to ask 





9 


https://hangouts.google.com 


E 


fal Barina https://plus.google.com 








Technically, the Single Site View is also part of site settings, but it has been bundled into the 
Origin Info Bubble section above (since it displays closer to what an origin info bubble would 
display). 


3.4.1 ‘All Sites’ List 

The behavior of the ‘All Sites’ list is of particular interest, since it is responsible for grouping 
multiple types of content settings into a single ‘origin’ entry, as well as displaying a 
human-readable origin to the user. 


To display a human-readable origin to the user, the following logic is used: 


e The port is only shown if it is non-standard (443 for HTTPS and 80 for HTTP) 
e If embedded in another page, the entry in the list has the additional text ‘Embedded on 
<origin>’. 


Grouping of content settings occurs so website settings other than permissions appear in their 
correct site (and don’t appear as a separate entry in the sites list, even though they have a 
slightly different primary pattern). This only affects two settings for now: 


1. Local storage: the primary pattern for local storage has a wildcard for the port (that is, 
the local storage of a site is accessible by all ports for that site’s host and scheme). 
Finding the ‘matching’ site for this is trivial, since it can be grouped with any sites that 
have the same host and scheme (there may be multiple). 

2. Cookies: there is currently no agreement on how best to display cookies for a site, since 
they are accessible across all sites with the same host (except secure cookies, which 


require the same HTTPS scheme as well). One solution might be to have cookies 
appear in all sites where the cookie is accessible, although this may result in duplicate 
cookie entries. 


4 A New Website Permissions class 


A new Website Permissions class is one way of safely abstracting all website permission-related 
functionality to ensure permissions are saved consistently and securely across Chrome. Existing 
permission callsites can be migrated one-by-one to use this class, with tests ensuring their 
current (broken) functionality is fixed. 


The class could provide the following behavior, any or all of which could be moved to a more 
central location (e.g. gurl.h or origin.h) if enough other callsites required the same functionality: 


1 Get an origin for display 


This functionality is required in the Origin Info bubbles @ _hitps:/exposure.so 0 min ago 
for displaying the origin of a site to a user, or in the Site 
Settings list for grouping permissions with the same 


Embedded on https://buzzfeed.com 


displayed origin together. The displayed origin may not E iitos://medium.com Enea 
include all information (such as the scheme, or the port i 
if it is the default), but is useful and meaningful for E https://teehanlax.com E AR 


displaying to a user. 


Would be used in: the origin info bubbles, site settings list, anywhere the origin is displayed (e.g. the notification) 


Currently performed by: ContentSettingsPattern::ToString(), UrlUtilities.getOriginForDisplay() 


2 Check if two URLs are from the same origin 





This would implement the RFC 6454 spec of an origin and EJ K FdA 14:14 
could be used throughout Chrome whenever a © settings 

same-origin policy test is needed. Furthermore, this could Filter 

eventually completely eliminate the need for patterns in Show all sites 

website permissions, calling this method for the current 
URL and any rule expected to match it instead of using 
the generalized pattern system. https://www.google.com.au:443 


https://www.google.com.au 


www.google.com.au x 


Would be used: for matching website permissions to URLs, throughout Chrome 


Currently performed by: ContentSettingsPattern: :Matches(), GURL: :GetOrigin(), Origin: :IsSameAs() 


3 Get/set a permission for a URL 


This would get/set the given website permission for 9 


Location 


the origin specified by the given URL. Under the hood, v 
it would use content settings to store the setting itself, 


as well as take into account the default value for the Block 
permission (if it has not been set) and whether or not O 


the permission is globally disabled. It would only 


return one of 3 values: Allow, Deny, or Ask. 


Allow 


Would be used: on a page when a permission is requested, in the origin info bubbles/site settings pages to 


display/save setting changes 


Currently performed by: HostContentSettingsMap: :Get/SetContentSetting() 


4 Get whether a permission is set to the default value on a URL 


Returns whether this permission has been set to 
anything non-default by the user for the given 
URL. Note that setting something that defaults 
to ‘Block’ back to ‘Block’ is not the same as 
setting it to the default value (which means the 
user has never set it at all). This is needed by 
certain dialogs to know whether or not to display 
the setting to the user. 


Permissions 


=œ] JavaScript 
Allow 


Q Location 
Allow 


Would be used: in the origin info bubbles/site settings pages to only display certain settings 


Currently performed by: HostContentSettingsMap::Get/SetContentSetting() (returns a special value 


when the setting is set to the default, and logic is needed at each callsite to get the default value separately) 


5 Get the default value of a permission 


This would get the default value for a website 
permission, as displayed on the global site 
settings page. Note that this is not needed at 
callsites since the function to get a permission for 
a URL already takes this default value into 
account. Also, although a setting might be set to 
the default value, it is still distinguishable from 
being set by the user (as opposed to having never 
been set at all). 


ua Fullscreen -09 


Allow sites to ask 


mm Images 


Allow 


Would be used: on the site settings page to display the default permission 


Currently performed by: HostContentSettingsMap::GetDefaultContentSetting() 


6 Globally enable/disable a permission 


Although a user cannot set the global default value for 
a permission, they can globally enable/disable it for all 
new sites that request it. This function does exactly 
that, and is also not needed at callsites since the Fullscreen 

i š , f i J 8 \ j —@ 
function to get a permission will return ‘Block’ if the E R een 
permission has been blocked for all sites, for example. 


t, Automatic downloads O 
Off - blocked for all sites 


P3 
kd 


Would be used: On the site settings pages that allow a user to globally enable/disable a permission 


Currently performed by: HostContentSettingsMap: :Get/SetContentSettingOverride() 


5 Future Work 


Although this new model helps ensure website permissions are saved consistently, there is still 
more work to do to ensure permissions are saved correctly and securely. Furthermore, ensuring 
the user has enough information to make a security decision is another problem that needs 
work. 


5.1 Other types of URLs 


One origin that has not been discussed is that of other types of URLs, such as internal Chrome 
URLs, or file and filesystem URLs. According to the Origin section of RFC 6454, file 
URLs may return an implementation-defined value, and they recommend globally unique 
identifiers for each file URI. Currently, content_settings pattern.cc returns a pattern that 
matches the same scheme and path as the given file URL, but with any hostname (this means 
that content settings for the file URL file://C/file.txt will apply to file://[.*]/file.txt, 
e.g. file: //D/file.txt). A more secure version of the origin for file URLs would likely include 
the host as well (and would match the RFC recommendation of returning a globally unique 
identifier for each file URI), which would mean each file:// URL has itself as its own unique 
origin. 


Similarly, granting permissions on filesystem URLs is also somewhat insecure - if a 
filesystem URL is used as a pattern, the filesystem scheme is ignored and the inner URL is 
taken and used to generate the pattern. This means that permissions granted on 
Filesystem://http://google.com/foo also grant to 
Ffilesystem://http://google.com/bar. Depending on the use case, this may be intended, 
but at a glance this seems insecure. 


5.2 Auto-granting iframe permissions 


As briefly discussed, the behavior regarding permission granting for iframes may have been an 
unintended result. However, it is secure (perhaps too secure) and an investigation into what 
may be considered ‘safe’ to auto-grant to the same origin when it appears nested inside a 
different page may be worthwhile. 


A new proposal for iframe behavior, Securing third-party permission usage, is currently 
underway that adds a new attribute to iframes to declare the permissions it requests. This could 


also pave the way for a new model in iframe website permission behavior, but that discussion is 
beyond the scope of this document. 


5.3 Contextual permission prompts 


Prompting at the right time and in the right way for certain permissions is key to helping the user 
understand what they are granting. The action bar on desktop is a great example of how to 
show when a permission is being used, but on Android the screen real-estate may make this too 
difficult to show in the same way. 


Similarly, once website permissions have been separated from content settings, maybe there 
could be a more generic way to model all the existing grant types (infobars, prompts, and 
strange behaviors like fullscreen and popups) as well as add new ones. Then, when new 
permissions are added to websites, adding a new kind of permission prompt would be easy and 
the permissions system would support a generic interface for any kind of UI. 


5.3.1 Inclusive/exclusive permissions 

In the category of contextual permissions also falls the idea of inclusive/exclusive permissions. 
For example, an improved location permission prompt might ask the user to select what location 
granularity they would like to provide (e.g. exact, city or country-level location). This could be 
represented as 3 separate permissions, or one permission with multiple permission settings. 
Either way, the system would need to be modified and extended to support this. 


Similarly, some permissions might automatically grant or ‘un-grant’ others. For example, 
granting the ‘Notifications’ or ‘Push messaging’ permission might automatically grant a “Run in 
the background’ permission, which is automatically revoked when both these permissions 
disappear. Although this functionality is not yet required, it could become useful as more 
complex permission rules are introduced. 


5.4 Permission auditing and preventing abuse 


One strategy to prevent permission abuse is to implement a strong auditing system that the user 
can easily access and interact with. The action icons that appear in the omnibox (e.g. the 
location icon when a site is using your location) are a good example of this. Another idea might 
be to add permissions to Chrome’s history section, which would now show not only when each 
site was visited, but when each site used a particular permission. Sites that abuse a given 
permission would quickly become apparent from this interface, and we can even identify these 
sites automatically and prompt users to consider revoking permission access on that site. 
Chrome could even collect this data and use it to automatically block permissions on sites that it 
knows to be abusive, and display an appropriate message to the user. 


Another possibility currently in progress is the idea of a ‘coins’ system for allocating background 
resources. This would automatically reduce the available permission usage (e.g. notifications) if 
a user was not interacting with them, helping to auto-block sites that use this resource for 
spamming. 


5.5 A site settings view on Desktop 


It has been mentioned before that although content settings exist on Desktop, there is no 
concept of a ‘sites list. One way of making web permissions more visible would be to bring a 
similar page to Android's Site Settings to Desktop. 


A design doc for a Chrome Resource Manager began some time ago, but the project is 
currently blocking on a full Ul review. If continued, this resource manager could provide the site 
settings experience that is currently missing on desktop. 


